Podniesienie uprawnień w SharePoint Workflow (zarówno w wersji 2010, jak i 2013) było dość łatwe. Służyły do tego przygotowane akcje.

To było przydatne rozwiązanie za każdym razem, gdy chcieliśmy, aby użytkownicy w trakcie procesu mogli aktualizować element, do którego nie mają bezpośrednich uprawnień do zapisu.

Jak odbywało się to w przepływach SharePoint 2010 i 2103?

To było dość proste. W trybie edycji należało kliknąć ikonkę „Impersonation Step” (SP 2010):

A jeśli miałeś dość szczęścia, by na farmie mieć Workflow Managera i w ten sposób obecne przepływy pracy SharePoint 2013, mogłeś użyć „App step” zamiast „Impersonation step”, pamiętając jednak o tym, by najpierw włączyć ficzer witryny „Workflow can use app permissions”:

I gotowe!

Przeczytaj więcej na ten temat na blogu Melissa Hubbard: https://melihubb.com/2017/04/11/app-step-vs-impersonation-step/

Jak podnieść uprawnienia w Power Automate?

Prawdopodobnie istnieje jeszcze więcej sposobów niż przedstawionych poniżej, jednak stoi za nimi jedna główna zasada: musisz stracić kontekst użytkownika, aby Flow używał poświadczeń zdefiniowanych dla połączenia podczas jego tworzenia (zazwyczaj autor Flow, ale możesz też stworzyć połączenie używając wcześniej przygotowanego „Konta serwisowego”).

Wyobraźmy sobie scenariusz: masz Flow, który obsługuje zatwierdzenia i jest uruchamiany po utworzeniu elementu (lub modyfikacji, lub w obu przypadkach). Chcesz teraz zmienić status w powiązanym elemencie za każdym razem, gdy zatwierdzanie się zakończy, jednak użytkownik, który zainicjował przepływ nie powinien mieć już uprawnień do modyfikacji elementu. Zobacz, jak można to rozwiązać.

1) Trigger poprzez Child Flow

Jest to najbardziej zalecane podejście. Jedynym warunkiem wstępnym do użycia jest to, że zarówno przepływy potomne, jak i nadrzędne muszą być przechowywane w solucji. W domyślnym środowisku solucje nic nie kosztują, ani przepływy potomne, dlatego takie podejście nie wymaga planów premium, w przeciwieństwie do pozostałych tu opisanych.

Aby go użyć, po prostu utwórz dwa przepływy wewnątrz solucji. Najpierw nadrzędny, w któym będzie znajdować się główna logika. Potem potomny. Przepływ potomny należy uruchomić za pomocą „Flow Button” jako wyzwalacza i akcji „Respond to PowerApps or Flow”, aby zwrócić dane do przepływu nadrzędnego:

Następnie wystarczy umieścić akcję w przepływie nadrzędnym „Run a Child Flow”, aby przekazać dane do przepływu podrzędnego i uzyskać wyniki:

Wszystkie akcje w przepływie potomnym będą uruchamiane przy użyciu połączeń zdefiniowanych podczas jego tworzenia. Upewnij się, aby skonfigurować ustawienia „Run only users”, zgodnie z moim postem tutaj: Szybki tip: flow nie może użyć child flow.

2) Trigger Flow poprzez HTTP Request

Utwórz drugi Flow, który będzie wyzwalany przy użyciu akcji „When a HTTP request is received”. Zdefiniuj treść żądania, np.:

{ "ItemID": 1, "NewStatus": "Completed" }

Pamiętaj także o użyciu akcji „Response”, dzięki czemu główny workflow będzie czekać aż do otrzymania odpowiedzi:

Potem po prostu użyj akcji „HTTP” w głównym przepływie, by zainicjować drugi Flow i przekazać mu parametry.

Pamiętaj, że użycie akcji HTTP w Flow wymaga subskrypcji Flow P1 dla twórcy i użytkowników wykonujących Flow.

3) Trigger Flow poprzez Azure Queue

W tym rozwiązaniu musisz ponownie utworzyć drugi przepływ, który będzie uruchamiany akcją „Azure Queue”. Następnie, gdy w głównym Flow zostanie zakończone zadanie, musisz po prostu umieścić wiadomość w kolejce, np .:

Następnie utwórz drugi przepływ, który odczyta tę wiadomość i odpowiednio zaktualizuje element SharePoint:

Dla tego rozwiązania nie potrzebujesz subskrypcji Flow P1, zamiast tego potrzebujesz subskrypcji Azure. Azure Queue korzysta z modelu „Pay-as-you-go” (sprawdź ceny: https://azure.microsoft.com/en-us/pricing/details/storage/queues/)

W tym podejściu główny przepływ nie będzie czekał na zakończenie drugiego przepływu, ponieważ działają one całkowicie niezależnie. Możesz jednak zbudować workaround, np. pętlę, która sprawdza, czy w kolejce są jakieś wiadomości i jeśli tak, czy istnieje komunikat z odpowiedzią z drugiego przepływu. Jeśli tak – kontynuuj działanie. W przeciwnym razie wstrzymaj na przykład na 10 sekund:

Możesz również zliczać wiadomości w kolejce, a gdy ich liczba wynosi 0 oznacza to będzie, że element jest zaktualizowany.

4) Trigger Flow poprzez Azure Service Bus

Podobnie jak w przypadku Azure Queue, Service Bus oferuje również kolejkę, w której podstawowy przepływ może zapisywać komunikat. Drugi przepływ będzie wyzwalany za pomocą akcji „When a message is received in queue” i w następstwie tego zaktualizuje element, by na koniec usunąć wiadomość z kolejki.

Do tego rozwiązania również potrzebujesz użyć subskrypcji Azure. Azure Service Bus korzysta z modelu „Pay-as-you-go” (sprawdź ceny: https://azure.microsoft.com/en-in/pricing/details/service-bus/)

Zapoznaj się także z poniższymi linkami, z których dowiesz się jakie są główne różnice pomiędzy Azure Service Bus i Storage Queue:

1. https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted
2. https://www.c-sharpcorner.com/UploadFile/fe6121/deep-dive-into-azure-storage-queue-vs-azure-service-bus-queu/

5) Użyj Azure Function

Ostatnim rozwiązaniem, o którym myślałem, jest funkcja Azure. Jest to jednak najbardziej skomplikowane podejście i nie widzę żadnych realnych korzyści. Ponadto, aby wywołać funkcję Azure, ponownie musisz to zrobić za pomocą HTTP lub Storage Queue, zatem wciąż musisz mieć subskrypcję P1 lub subskrypcję Azure.

Główną zaletą korzystania z funkcji Azure jest możliwość zarejestrowania jej w AAD i przyznania jej dostępu za pomocą „uprawnień aplikacji”:

Pozwoli to na realizację scenariusza, w którym element na liście jest faktycznie aktualizowany przez konto systemowe, a nie jakikolwiek sztucznie stworzone „konto usługi”.

Dziękuje za lekturę! Jeśli masz jakieś pytania, pozostaw je w polu komentarzy poniżej lub skontaktuj się ze mną bezpośrednio!